Communication devices such as wireless terminals are also known as e.g. user equipments (UE), mobile terminals, mobile stations and/or wireless communication devices. Wireless communication devices are enabled to communicate wirelessly in a cellular communications network or wireless communication system, sometimes also referred to as a cellular radio system or cellular networks. The communication may be performed e.g. between two wireless communication devices, between a wireless communication device and a regular telephone and/or between a wireless communication devices and a server via a Radio Access Network (RAN) and possibly one or more core networks, comprised within the cellular communications network.
Wireless communication devices may further be referred to as user equipments, mobile telephones, cellular telephones, laptops, tablet computers or surf plates with wireless capability, just to mention some further examples. The wireless communication devices in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the RAN, with another entity, such as another wireless communication devices or a server.
The cellular communications network covers a geographical area which is divided into cell areas, wherein each cell area being served by an access node. A cell is the geographical area where radio coverage is provided by the access node.
Wireless communication devices may comprise wireless baseband modems and application processors which are based on Central Processing Units (CPUs) that can be designed based on a core e.g. from ARM such as CORTEX R5 or A15. Usually CPUs are implemented on Integrated Circuits (IC) called a Digital Baseband (DB) and regulated supply voltages are provided by another IC called a Power Management Unit (PMU) which also is referred to as an Analog Baseband (AB).
CPU crashes i.e. unexpected shutdowns of wireless communication devices are usual during a software development phase. Usually they are due to issues in the software code and there are dedicated tools called debuggers available to trace the source of the issue causing the CPU to either hang or shutdown the wireless communication device.
CPU malfunctions may also be caused by errors in hardware e.g. in one of the ICs or Printed Wiring Boards (PWB/PCB) or there could be errors in the design of the IC or error in the software that controls the IC.
One source for a hardware failure could be that the regulator inside PMU that is supplying power to the CPU fails for some reason, the failure could also be the supply to the oscillator, memory or other vital component of the CPU subsystem. The regulator could be incorrectly configured by the software or the communication from the DB to the PMU could fail or the regulator core may not provide the specified voltage and current supply.
CPU power supply failure can cause several consequences in the wireless communication device and the most usual one is CPU crashes i.e. resetting to initial state, getting stuck, performing unexpected tasks or entering various internal error states. The commonality for all power supply crashes is that software debugger tools are not able to provide the actual reason of the failure instead it provides no reason or a reason that is not the root cause but the consequence of the failure e.g. memory corruption.
Software debugger tools may detect from the CPU dump file which describes the state of the CPU memory and registers at the moment of the failure that there was unexpected shutdown of the PMU. In case of the battery line being under or over voltage it may be relatively easy to trace the source of the error being a faulty battery supply. A PMU internal Watch Dog (WD) expiration can be used to investigate the supply error of the CPU that is running software expected to keep the WD alive.
CPU crashes that are not traceable with software debugger tools need to be investigated in laboratory with measurement equipment like oscilloscope. In order to capture the failure with an oscilloscope it requires being able to access the test points and find the right use case to trigger the failure again.
An unexpected shutdown event in a CPU dump file is often hard to diagnose. For example sometimes battery overvoltage is not caused by a battery failure but e.g. by software that programs PMU settings in such way that the CPU or PMU causes disturbances on the battery line. Also the PMU internal watchdog expiration can be caused by a supply problem of many other devices like memory or general interface (IO) supply voltage failure. It can also happen that the actual unexpected shutdown event is not recorded in the CPU dump file. This is due to fact that there is no system restart because the PMU internal watchdog is intentionally disabled. The watchdog may be kept alive but otherwise CPU is not working well or in worst case the CPU is damaged by the power supply failure.
In early development phase of wireless communication devices it can be relatively easy to capture the CPU power supply failures from the development boards with measurement equipment like oscilloscopes but it is always time consuming and cumbersome. Later in the product development cycle it may be impossible to capture the failure if it happens in the customer device and occurrence is low or conditions cannot be reproduced in laboratory.